This same bug affects all other versions, too.

I'm about to give up writing the test coverage for this change because codecov keeps complaining about everything I try. (Especially I didn't understand why it demands test coverage for the tests, too.) My idea is to add binary data to the LDAP response, e.g., a minimal GIF image as the LDAP attribute thumbnailPhoto, as this is a common case where LDAP returns binary data.

{
    "dc=users_ldap_groups,dc=example,dc=com": {
        "cn": [b"User Name"],
        "name": [b"hello", b"hello2"],
        "thumbnailPhoto": [
            b"GIF89a\x01\x00\x01\x00\x00\xff\x00,"
            b"\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x00;"
        ],
    }
}

Tested with Odoo 16.0.20240102 on Ubuntu 22.04.

This decode-that-encodes-in-base64 looks a bit weird to me. Why is the decode necessary in the first place?

Perhaps, to move faster, you could do the security fix in a PR, so I can merge this, and do the decode improvement in another PR and work on that one with folks who are more familiar with this module?

This decode-that-encodes-in-base64 looks a bit weird to me. Why is the decode necessary in the first place?

This simply replaces the original ldap_entry[1][attr][0].decode() doing the fix with the least possible modifications to the module. The Str.decode() was added in ad15e3a when migrating the module from Odoo 10 to Odoo 12 and seems quite necessary, because it did not work without it on the first attempts to address this bug. The contains & equals uses the Str.decode() (in x.decode()), too, so not using it here does not seem coherent, either. Although not explained in the commit, I guess the root cause might be support for non-ASCII names.

So, why not use this safe_ldap_decode() in contains & equals then? Because only the requested LDAP attributes are compared and they should never contain binary data. This is a special case for the query operator for which LDAP returns the entire Active Directory object with all the attributes.

Does this satisfactorily explain the situation here?

Perhaps, to move faster, you could do the security fix in a PR

@sbidoul: There's now another PR #659 that only contains the commit fixing the vulnerability. After merging that this PR is only the second commit ahead of upstream 16.0 branch.

Rebased to fix the checks that didn't pass; the problem was in another module.

Could someone please review & merge this already?

Rebased over fc906889df964a3f8b50013389dbc585aee0080a after workflow fixed in #693.

@sbidoul It seems difficult to get anyone that actually knows something about LDAP to review this fix. However, this has been running on an instance for months and has fixed a real-life problem there. The problematic LDAP response has been demonstrated in a new test this PR adds, and all the previous tests are passing, too. Could this finally be merged?

What a great day to merge this nice PR. Let's do it!
Prepared branch 16.0-ocabot-merge-pr-596-by-pedrobaeza-bump-patch, awaiting test results.

Congratulations, your PR was merged at d4fee8b. Thanks a lot for contributing to OCA. ❤️